Skip to content

fix(packaging): inline the fast-uri URIComponent type; drop stale typesVersions#2394

Merged
felixweinberger merged 6 commits into
mainfrom
fweinberger/packaging-dts-fixes
Jun 30, 2026
Merged

fix(packaging): inline the fast-uri URIComponent type; drop stale typesVersions#2394
felixweinberger merged 6 commits into
mainfrom
fweinberger/packaging-dts-fixes

Conversation

@felixweinberger

Copy link
Copy Markdown
Contributor

Re-cut of the surviving pieces of #2362 onto current main (that branch predates the integration merge and is impractical to rebase — its json-schema-typed dts.resolve fix is already on main, and the validator-type reorganization is superseded by the current root-barrel treatment).

Motivation and Context

Consumers compiling with skipLibCheck: false hit two declaration-file issues found by a fresh-install smoke (npm install + tsc --noEmit):

  • The bundled client/server .d.mts leaves a dangling URIComponent reference: ajv@8.18's published types import it from fast-uri, which ships its types as an export-assigned namespace the dts bundler cannot destructure into a named import — the import is dropped and the bare reference remains (TS2304). A dts-only path mapping now points fast-uri at a small declaration shim so the type is inlined; runtime code is unaffected.
  • @modelcontextprotocol/node carried a stale typesVersions entry pointing at a subpath that no longer ships.
  • Client/server READMEs now note that TypeScript ≥6.0 requires "types": ["node"] since the published declarations reference Buffer.

How Has This Been Tested?

Built client and server and verified the bundled .d.mts: no import statements referencing fast-uri or json-schema-typed remain, and URIComponent is declared inline with its uses resolving. A consumer smoke compiles against the built declarations with skipLibCheck: false (exit 0). Package typechecks clean.

Breaking Changes

None.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

Supersedes the packaging half of #2362, which can be closed.

…esVersions

The bundled client/server .d.mts left a dangling URIComponent reference:
ajv@8.18's published types import it from fast-uri, which ships its types
as an export-assigned namespace the dts bundler cannot destructure, so the
import was dropped and the bare reference remained (TS2304 for consumers
compiling with skipLibCheck: false). A dts-only path mapping now points
fast-uri at a small declaration shim so the type is inlined. Runtime code
is unaffected.

Also drops @modelcontextprotocol/node's stale typesVersions entry for a
subpath that no longer ships, and notes in the client/server READMEs that
TypeScript >=6.0 needs "types": ["node"] because the published
declarations reference Buffer.

The json-schema-typed dts.resolve fix from the original branch is already
on main; the validator-type subpath reorganization is superseded by the
current root-barrel treatment.
@felixweinberger felixweinberger requested a review from a team as a code owner June 30, 2026 13:39
@changeset-bot

changeset-bot Bot commented Jun 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: a8b5297

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages
Name Type
@modelcontextprotocol/server Patch
@modelcontextprotocol/client Patch
@modelcontextprotocol/node Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@pkg-pr-new

pkg-pr-new Bot commented Jun 30, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2394

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2394

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2394

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2394

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2394

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2394

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2394

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2394

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2394

commit: a8b5297

Complete the fast-uri URIComponent shim to a field-for-field copy of
fast-uri@3.1.0 (the first cut carried 9 of 14 fields; consumers
implementing a custom uriResolver would have seen property errors on the
URN/WebSocket fields) and pin the source version in the comment.

Add a dist-types smoke to CI: compiles a small consumer against the built
.d.mts of client and server (root + validators/ajv subpath) with
skipLibCheck: false. The dts bundler emits dangling-reference cases only
as non-fatal warnings - its failOnWarn setting does not fail on them - so
nothing else catches a dependency bump that reintroduces one.

Rename and reword the changeset: the previous file name and text described
an earlier approach; the entry now also covers the json-schema-typed
inlining, which this branch relies on from dts.resolve.
Comment thread packages/middleware/node/package.json
Comment thread scripts/smoke-dist-types.mjs
…st-types smoke

Review follow-up: the smoke is the only hard gate for dangling references
in the built declarations, so it now also compiles validators/cf-worker and
stdio for both packages, not just the root and the ajv subpath.
@felixweinberger felixweinberger force-pushed the fweinberger/packaging-dts-fixes branch from 010b1dc to b3a2932 Compare June 30, 2026 14:25
felixweinberger and others added 3 commits June 30, 2026 14:29
…erver

Review follow-up: same class as the node sse entry this PR removes - the
mapping points at dist/zodSchemas.d.mts, which has no source, no build
entry, and no exports subpath, so it never shipped.
@felixweinberger felixweinberger merged commit 801111e into main Jun 30, 2026
18 checks passed
@felixweinberger felixweinberger deleted the fweinberger/packaging-dts-fixes branch June 30, 2026 14:48
Comment thread packages/server/README.md
npm install @modelcontextprotocol/server@alpha
```

TypeScript ≥6.0 no longer auto-includes `@types/*` — add `"types": ["node"]` to your `tsconfig.json` `compilerOptions` (the published `.d.mts` references `Buffer`).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 The new TS ≥6.0 note says consumers must add "types": ["node"] to compilerOptions, but the repo's own quickstart docs (docs/server-quickstart.md lines 99-116 and docs/client-quickstart.md lines 88-105) still present canonical tsconfig.json examples without a types entry while installing @types/node and using Node APIs (readline, process). Consider adding "types": ["node"] (or the same caveat) to those two quickstart tsconfig snippets so a TS ≥6.0 user following them verbatim doesn't hit exactly the problem this note warns about.

Extended reasoning...

What it is. This PR adds a note to packages/client/README.md and packages/server/README.md stating that TypeScript ≥6.0 no longer auto-includes @types/* and that consumers must add "types": ["node"] to their tsconfig.json compilerOptions (because the published .d.mts references Buffer). However, the repo's own consumer-facing setup docs — docs/server-quickstart.md (tsconfig at ~lines 99-116) and docs/client-quickstart.md (tsconfig at ~lines 88-105) — each present a complete, canonical tsconfig.json for new users that contains no types field, and were not updated by this PR.

The code path that triggers it. Both quickstarts instruct npm install -D @types/node typescript (i.e. latest TypeScript) and then ship sample code that relies heavily on Node APIs: the client quickstart imports readline/promises and uses process.argv, process.env, process.exit, process.stdin/stdout; the server quickstart uses console.error and the stdio transport. Under TS ≥6.0 (per the PR's own claim, verified by the author via the fresh-install smoke), @types/node is no longer auto-included from node_modules/@types, so without an explicit "types": ["node"] (or a triple-slash reference) those globals and modules are unresolved.

Why existing code doesn't prevent it. The quickstart tsconfig sets skipLibCheck: true, but that only suppresses errors inside declaration files (e.g. the dangling Buffer reference in the bundled .d.mts); it does not make Node globals or node:/readline/promises module types resolvable in the user's own code. Nothing else in the quickstart flow adds the types entry.

Step-by-step proof. (1) A new user follows docs/client-quickstart.md verbatim with TypeScript 6.x: npm install -D @types/node typescript, copies the tsconfig at lines 88-105, copies the sample client code (which imports readline/promises and uses process.*). (2) They run npx tsc. (3) Because TS ≥6.0 no longer auto-includes @types/* and the tsconfig has no types entry, the compiler cannot resolve readline/promises or the process global → TS2307 / TS2580-style errors in the user's own files, which skipLibCheck: true cannot mask. (4) The fix is exactly the guidance this PR adds to the READMEs — "types": ["node"] — but the quickstart, which is the canonical setup doc, never mentions it.

Impact and fix. This is a doc-consistency gap, not a code bug, and the quickstarts were equally untouched before this PR (the underlying need comes from TypeScript 6, not from this change) — hence nit severity, not blocking. The repo's review conventions call for checking whether docs/**/*.md describes old behavior when guidance changes; since this PR introduces the types: ["node"] guidance, the cheapest complete fix is a one-line addition of "types": ["node"] to the two quickstart tsconfig snippets (or a parallel one-sentence caveat next to them), which can be done in this PR or as an immediate follow-up.

All four verifiers independently confirmed the quickstart tsconfig snippets lack a types entry while the sample code depends on Node APIs, and all rated this nit-level; there were no refutations.

@claude claude Bot mentioned this pull request Jun 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant